Because of the efficiency of modern networks, most users of networks such as the Internet or mobile phones assume that their communication is essentially point-to-point, such as laptop-to-server or phone-to-phone. They know there is some form of router or service provider or cell phone tower in between, but otherwise they generally may remain happily unaware of the complexity of functions performed on the data packets they are creating, transmitting and receiving, the paths the packets take to have these functions performed or, indeed, for most users, that there are packets involved at all.
In the context of network-based data transmission, a packet is generally understood to be a body of data that traverses a network as a unit, as opposed to a continuous bit stream. Larger data sets may be subdivided, either as a function of time, or of size, or both, into packets, which carry the data of the larger set. In some other situations, packets are created as primary data carriers, independent of any larger data set. In either case, packets also typically carry metadata that relate to the packets themselves and usually the path they take through the network from their respective insertion or origin points to their endpoints.
Packets may, and usually are, processed in any of a great number of different ways on their route from their source to their destination. Each such processing stage is normally referred to as a “service function” (SF). An SF is thus a network function that provides any form of either transformation or other value added service. Deep Packet Inspection, a firewall, an IP Network Address Translator (NAT), a load balancer, Intrusion Defense and Intrusion Prevention Systems (IDS/IPS), and Lawful Intercept (LI) are just a few of the almost countless examples of SFs, many more of which may be defined by the system administrator.
As a packet moves through a network, it may encounter one or more such SFs in order. The ordered set of SFs and any ordering constraints that are to be applied to a given packet is known as its Service Function Chain (SFC), sometimes referred to more simply as its “service chain,” and sometimes also referred to as a VNFFG (Virtual Network Function Forwarding Graph). The SFC represents an evolution toward interconnected, orchestrated, and automated software-defined networks and network virtualization function implementations. The packet path defined by a SFC from an initial logical position (“source”) at a first node to a destination need not be strictly linear; rather, a packet path may be branched, either conditionally or as a result of packet copying, path branches may merge, and it is even possible for a SFC to define a path that leads through a given node and SF more than once.
In some cases, each SF is performed by a separate node, such as a different server. In other cases, more than one SF is performed in a single node, for example, simply as parts of a single routine, or by separate virtual machine instances, etc.
It is typically required for the source-to-destination flow of data packets to follow a clearly defined path through the network. Even where not required, it is at least usually preferable to know that path. For example, packets may be specified to go through a performance optimizer, then a firewall, then a load balancer, and maybe a VPN server before reaching a destination server. Troubleshooting flow errors is at present difficult, often uncertain, and usually slow, especially inasmuch as it is usually manual: when an anomaly is detected in the chain, in current systems, the point of failure is not automatically flagged. The degree of troubleshooting complexity increases greatly in environments in which several co-existing tenants/clients, each with their own separate SFC requirements, may dynamically need to change the SFC routing and the SFs involved.
What is needed is a way to more efficiently verify the flow of packets as they follow a SFC through a network.